UCF STIG Viewer Logo
Changes are coming to https://stigviewer.com. Take our survey to help us understand your usage and how we can better serve you in the future.
Take Survey

All containers must be restricted to mounting the root filesystem as read only.


Overview

Finding ID Version Rule ID IA Controls Severity
V-260936 CNTR-MK-001160 SV-260936r966165_rule Medium
Description
The container's root filesystem must be treated as a "golden image" by using Docker run's --read-only option. This prevents any writes to the container's root filesystem at container runtime and enforces the principle of immutable infrastructure. Enabling this option forces containers at runtime to explicitly define their data writing strategy to persist or not persist their data. This also reduces security attack vectors since the container instance's filesystem cannot be tampered with or written to unless it has explicit read-write permissions on its filesystem folder and directories.
STIG Date
Mirantis Kubernetes Engine Security Technical Implementation Guide 2024-06-17

Details

Check Text ( C-64665r966163_chk )
When using Kubernetes orchestration, this check is Not Applicable.

For Swarm orchestration, check via CLI:

Linux: As an MKE Admin, execute the following command using a Universal Control Plane (MKE) client bundle:

docker ps --quiet --all | xargs -L 1 docker inspect --format '{{ .Name }}: ReadonlyRootfs={{ .HostConfig.ReadonlyRootfs }}'

If ReadonlyRootfs=false, it means the container's root filesystem is writable and this is a finding.
Fix Text (F-64573r966164_fix)
When using Kubernetes orchestration, this check is Not Applicable.

When using Swarm orchestration, review and remove nonsystem containers previously created by these users with read write permissions using:

docker container rm [container]

Add a --read-only flag at a container's runtime to enforce the container's root filesystem to be mounted as read only:

docker run --read-only

Enabling the --read-only option at a container's runtime must be used by administrators to force a container's executable processes to only write container data to explicit storage locations during the container's runtime.

Examples of explicit storage locations during a container's runtime include, but are not limited to:

1. Use the --tmpfs option to mount a temporary file system for nonpersistent data writes. Example:

docker run --interactive --tty --read-only --tmpfs "/run" --tmpfs "/tmp" [image] [command]

2. Enabling Docker rw mounts at a container's runtime to persist container data directly on the Docker host filesystem. Example:

docker run --interactive --tty --read-only -v /opt/app/data:/run/app/data:rw [image] [command]

3. Utilizing Docker shared-storage volume plugins for Docker data volume to persist container data.

docker volume create -d convoy --opt o=size=20GB my-named-volume

docker run --interactive --tty --read-only -v my-named-volume:/run/app/data [image] [command]